Что такое SBOM

Что такое перечень программных компонентов (SBOM)


Январь 11, 2024


Растущая частота и агрессивность кибератак, включающих в себя атаки на цепочку поставок программного обеспечения, заставляют специалистов по информационной безопасности внедрять в процессы разработки дополнительные меры по защите ИТ-инфраструктуры. Одна из таких мер — использование перечня программных компонентов ПО, который позволяет повысить прозрачность инфраструктуры и предотвратить появление скрытых уязвимостей, чаще всего становящихся для злоумышленников «открытыми дверьми» в проект.

В этой статье рассмотрим, что такое перечень программных компонентов программного обеспечения, какие преимущества он несет всем сторонам, работающим с ПО (как разработчикам, так и заказчикам), и как его создать.

Что такое SBOM

Перечень программных компонентов (software bill of materials, SBOM) — это перечень всех модулей и библиотек, необходимых для сборки программного продукта, а также указателей их связи друг с другом. SBOM похож на ведомость материалов — список сырья и материалов, необходимых для изготовления и сборки продукта. При этом SBOM содержит не только наименование, но и имя поставщика, версию и другие важные идентификаторы (более подробно содержание SBOM обсуждается в разделе «Какие данные входят в SBOM»).

Следует отметить, что SBOM содержит информацию как об опенсорсных, так и проприетарных зависимостях, но это не значит, что разработчикам ПО придется раскрывать закрытый исходный код. Перечень компонентов не включает в себя описание того, как эти компоненты используются в процессе построения архитектуры приложения.

Как SBOM помогает повысить безопасность приложений

Наличие перечня программных компонентов у программного продукта несет в себе ряд преимуществ как для разработчиков, так и компаний, использующих данное ПО в корпоративном проекте.

Предотвращение скрытых уязвимостей

Поскольку в крупном проекте используются сотни зависимостей, следить за наличием уязвимостей сложно. При этом уязвимости могут содержаться как в опенсорсных, так и проприетарных компонентах, просто в последнем случае о них нет информации в свободном доступе. Перечень программных компонентов содержит в себе информацию обо всех известных уязвимостях, поэтому разработчики могут сразу оценить состояние проекта и обновить устаревшие компоненты (при наличии свежей версии с патчем) или заменить их на более безопасные.

Контроль версий и состояния зависимостей

Опенсорсные пакеты ПО могут разрабатываться и поддерживаться крупными компаниями, небольшими сообществами или даже одним разработчиком. Иногда такой проект обновляется нерегулярно или вообще забрасывается, но при этом ИТ-команда продолжает его использовать в корпоративном приложении. SBOM помогает отследить версии зависимостей и понять, используете вы новую или устаревшую версию.

Снижение риска проблем, связанных с нарушением условий лицензирования ПО

Любое программное обеспечение лицензируется. Существует большое количество лицензий ПО, и, если не знать, действие какой лицензии распространяется на используемую зависимость (даже опенсорсную), это может вызвать юридические проблемы. Например, модуль нельзя использовать в коммерческом продукте в соответствии с условиями лицензии. Еще один пример — лицензия GLP без CPE, из-за которой любой код, использующий зависимость под этой лицензией, должен быть открыт.

SBOM содержит информацию о лицензировании программных компонентов, что позволяет избежать рисков непредумышленного нарушения лицензионного соглашения.

Суммируя вышесказанное, SBOM помогает разработчикам контролировать целостность используемых зависимостей, DevSecOps-экспертам — мониторить наличие уязвимостей в проекте и своевременно реагировать на их появление, а заказчикам — убедиться в безопасности поставляемого продукта.

Какие данные должны входить в SBOM

Регламенты по составлению перечня программных компонентов ПО находятся в активной разработке, поэтому сейчас есть перечень обязательных данных о компонентах ПО, которые должны быть включены в SBOM. Возможно, в будущем этот список будет дополнен.

Прежде всего, необходимо указать ключевую информацию о компоненте и поставщике:

  • Название и версия компонента,
  • Наименование поставщика,
  • Уникальные идентификаторы, с помощью которых можно найти компонент в базах данных,
  • Тип зависимости (прямая или транзитивная), которое указывает на отношение компонента и программного продукта.

Помимо этого, необходимо указать автора SBOM и временную метку (дату создания перечня).

Как создать SBOM

Перечень программных компонентов должен быть сгенерирован в общепринятом, машинно-читаемом формате, что позволяет встроить SBOM в автоматизированные процессы мониторинга безопасности ПО.

В настоящее время существует три стандартных формата SBOM:

  • Software Package Data eXchange (SPDX) от Linux Foundation,
  • CycloneDX от OWASP Foundation,
  • Идентификационные теги ПО (SWID), соответствующие стандарту ISO/IEC 19770-2:2015.

Для генерации SBOM в любом из выбранных форматов можно воспользоваться специальными инструментами. Например, SBOM для Java-приложения в формате SPDX или CycloneDX можно получить с помощью плагина CycloneDX для Maven, плагина CycloneDX для Gradle или SPDX CLI для Maven.

Кроме того, при внедрении SBOM в жизненный цикл безопасной разработки (SDL) следует учитывать следующее:

  • С каждым релизом или обновлением программного продукта необходимо генерировать новый SBOM.
  • В SBOM необходимо включать как прямые, так и транзитивные зависимости, но глубина транзитивности определяется разработчиками или заказчиком ПО.
  • В случае, если информация о зависимостях компонента неполная или отсутствует, необходимо это указать.

SBOM — первая линия защиты ИТ-инфраструктуры

Перечень программных компонентов не заменяет, но дополняет обязательные меры по обеспечению информационной безопасности, принятые в компании. SBOM помогает разработчикам понять, есть ли в их проекте уязвимые ПО, а заказчикам — быть уверенными в надежности приобретаемого программного продукта.

Безопасность ваших приложений для команды Axiom JDK — приоритет. Все продукты семейства Axiom JDK разрабатываются в соответствие с концепцией жизненного цикла безопасной разработки и проходят многочисленные тесты перед каждым релизом. Мы также предоставляем заказчикам SBOM для наших продуктов. Свяжитесь с нами, и наши инженеры расскажут вам более подробно об услуге.

Author image

Роман Карпов

Директор по стратегии и развитию технологий Axiom JDK

Команда Axiom JDK roman.karpov@axiomjdk.ru Команда Axiom JDK logo Axiom Committed to Freedom 199 Obvodnogo Kanala Emb. 190020 St. Petersburg RU +7 812-336-35-67 Команда Axiom JDK 199 Obvodnogo Kanala Emb. 190020 St. Petersburg RU +7 812-336-35-67